Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug fixes for max net metering benefit, multi-period and multi-tier demand charges #401

Merged
merged 29 commits into from
Jun 11, 2024

Conversation

zolanaj
Copy link
Collaborator

@zolanaj zolanaj commented May 22, 2024

Fixed

  • Increased the big-M bound on maximum net metering benefit to prevent artificially low export benefits
  • Fixed a bug in which tier limits did not load correctly when the number of tiers vary by period in the inputs

@zolanaj
Copy link
Collaborator Author

zolanaj commented May 22, 2024

addresses #386

@zolanaj zolanaj requested a review from adfarth May 24, 2024 16:51
@adfarth
Copy link
Collaborator

adfarth commented May 24, 2024

Checked and confirmed that these fixes address previous issues in results from these posts:
high_wholesale.json
high_energy_rate_max.json

CHANGELOG.md Show resolved Hide resolved
src/core/urdb.jl Outdated Show resolved Hide resolved
@adfarth
Copy link
Collaborator

adfarth commented May 28, 2024

@zolanaj Done reviewing with just two remaining comments!

@zolanaj
Copy link
Collaborator Author

zolanaj commented May 31, 2024

Tagging issue #297 ads this may be addressed now?

Also added issue #297 for future bigM improvement.

@adfarth
Copy link
Collaborator

adfarth commented May 31, 2024

Tagging issue #297 ads this may be addressed now?

Also added issue #297 for future bigM improvement.

Regarding #297 , documenting that currently the below (a) results in tier_limits: [100.0, 1.0e8] and (b) results in tier_limits: [1.0e8, 1.0e8]

(a)

"demandratestructure": [
                [
                    {
                        "max": 100000000000000000000000000000000000000,
                        "rate": 15
                    }
                ],
                [
                    {
                        "max": 100,
                        "rate": 25
                    },
                    {
                        "max": 100000000000000000000000000000000000000,
                        "rate": 35
                    }
                ]
            ],

(b)

[
                    {
                        "max": 100,
                        "rate": 25
                    },
                    {
                        "max": 100000000000000000000000000000000000000,
                        "rate": 35
                    }
                ],
                [
                    {
                        "max": 100000000000000000000000000000000000000,
                        "rate": 15
                    }
                ]

@zolanaj
Copy link
Collaborator Author

zolanaj commented Jun 3, 2024

@adfarth Ready for you to check again! There are more tests in the new set and the limits are now indexed on month (or ratchet).

@zolanaj zolanaj requested a review from adfarth June 3, 2024 23:30
src/core/urdb.jl Outdated Show resolved Hide resolved

for tier in range(1, stop=n_energy_tiers)

for month in range(1, stop=12)
period = Int(d["energyweekdayschedule"][month][1] + 1)
for tier in range(1, stop=n_energy_tiers)
# tiered energy schedules are assumed to be consistent for each month (i.e., the first hour can represent all 24 hours of the schedule).
Copy link
Collaborator

@adfarth adfarth Jun 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this means that if you have a rate with multiple periods within a month, and the tier maxes (kWh) vary between those periods, REopt will overwrite the tier max values for all periods that are not the hour 1 period, using hour 1 period maxes.

For example, period 1 here would be assumed to have a 1st tier max of 88 in May-Sept, and a 1st tier max of 100 in Nov (given the resulting energy_tier_limits matrix shown below); is that a correct interpretation?
energy_tier_limits_kwh: [88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 100.0 1.0e10; 88.0 1.0e10]
image

Is it accurate to say this is still not fully capturing the intended rate, but is one step better than what we did before, which was assume that all periods[tiers] had the same max limits?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this means that if you have a rate with multiple periods within a month, and the tier maxes (kWh) vary between those periods, REopt will overwrite the tier max values for all periods that are not the hour 1 period, using hour 1 period maxes.

For example, period 1 here would be assumed to have a 1st tier max of 88 in May-Sept, and a 1st tier max of 100 in Nov (given the resulting energy_tier_limits matrix shown below); is that a correct interpretation? energy_tier_limits_kwh: [88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 88.0 1.0e10; 100.0 1.0e10; 88.0 1.0e10] image

Is it accurate to say this is still not fully capturing the intended rate, but is one step better than what we did before, which was assume that all periods[tiers] had the same max limits?

That's correct if we are talking about monthly rates and limits, but the time-of-use "ratchets" allow for custom definition of periods and so this setup likely assigns a separate "ratchet" that consists of thirty hourly periods from 12-1am and another for all the other hours in November, each of which has its own separate tiers and limits. I'd expect to see 18 time-of-use periods in this setup, each of which has two tiers.

So, to that end: is the above matrix what's actually produced when you insert this custom output or do you get the 2x18 matrix? One thing I did not touch as part of this PR is the logic for when custom time-of-use vs. monthly tiers are generated. We can revisit that, but it's likely best reserved for an issue at this point.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

piggybacking on this comment: what I said above applies to demand charges but not energy rates, so this is a missing feature as compared to everything that the URDB rate builder allows for.

src/core/urdb.jl Outdated Show resolved Hide resolved
CHANGELOG.md Outdated Show resolved Hide resolved
test/runtests.jl Outdated Show resolved Hide resolved
Copy link
Collaborator

@adfarth adfarth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zolanaj Approving with just a few comments requesting updates to help text and a few questions to help me understand the changes. Thanks for making these improvements and fixes!

@adfarth
Copy link
Collaborator

adfarth commented Jun 10, 2024

@zolanaj Adding one more thing that we can definitely punt to another PR unless you think it makes sense to address here:

It looks like the ["ElectricUtility"]["interconnection_limit_kw"] is currently not getting applied to wholesale techs (only to net metering techs). I confirmed this by (looking at the constraints and) running a scenario with a wholesale rate and an interconnection limit. REopt sizes over the interconnection limit but still receives WHL compensation for exports.

@zolanaj
Copy link
Collaborator Author

zolanaj commented Jun 11, 2024

It looks like the ["ElectricUtility"]["interconnection_limit_kw"] is currently not getting applied to wholesale techs (only to net metering techs). I confirmed this by (looking at the constraints and) running a scenario with a wholesale rate and an interconnection limit. REopt sizes over the interconnection limit but still receives WHL compensation for exports.

Great catch! I'm adding an issue here: #416

@zolanaj
Copy link
Collaborator Author

zolanaj commented Jun 11, 2024

@zolanaj Approving with just a few comments requesting updates to help text and a few questions to help me understand the changes. Thanks for making these improvements and fixes!

Thanks for the thorough review @adfarth! after making some edits in response to this last round I will merge once tests are confirmed to pass.

@zolanaj zolanaj merged commit ea92b7c into develop Jun 11, 2024
1 check passed
@zolanaj zolanaj deleted the fix-net-metering-and-demand-charges branch June 11, 2024 19:59
@zolanaj zolanaj mentioned this pull request Jul 3, 2024
indu-manogaran pushed a commit that referenced this pull request Sep 16, 2024
bug fixes for max net metering benefit, multi-period and multi-tier demand charges
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants